Abordando a arquitetura MVC, e Design Patterns: Observer, Composite, Strategy

Em busca de software de qualidade e segurança e em prazos cada vez menores, cada vez mais percebemos a suma importância de utilizar design patterns, neste artigo abordamos a arquitetura MVC (Model, View, Controller) explicando-a com a ajuda de um conjunto de padrões de projetos trabalhando juntos numa mesma estrutura, e sua participação para atender os mais variados requisitos na construção de projeto que possa ser escalável e que possíveis alterações em quaisquer das camadas seja feita sem interferência nas outras camadas, o MVC baseia-se na separação de dados (modelo), da interface com o usuário (view) e da lógica de negocio (controller), também descreveremos uma noção de anti-padrões que por sua vez se parece com um padrão de projeto que possui suas vantagem e desvantagens.

por Adriano José Baptistella

Resumo: Ao depararmos com um projeto podemos usufruir de abordagens sistemáticas e disciplinadas, e á encontramos na engenharia de software usando design patterns. Em busca de software de qualidade e segurança e em prazos cada vez menores, cada vez mais percebemos a suma importância de utilizar design patterns, neste artigo abordamos a arquitetura MVC (Model, View, Controller) explicando-a com a ajuda de um conjunto de padrões de projetos trabalhando juntos numa mesma estrutura, e sua participação para atender os mais variados requisitos na construção de projeto que possa ser escalável e que possíveis alterações em quaisquer das camadas seja feita sem interferência nas outras camadas, o MVC baseia-se na separação de dados (modelo), da interface com o usuário (view) e da lógica de negocio (controller), também descreveremos uma noção de anti-padrões que por sua vez se parece com um padrão de projeto que possui suas vantagem e desvantagens.

Palavras chave:

Design patterns, Padrões de Projeto, Engenharia de Software, MVC (Modelo, Visão, Controle), Anti-padrões.

1. Introdução

          Em décadas anteriores, um software era desenvolvido para rodar em uma única máquina este aplicativo possuía apenas uma camada, nestas aplicações era gerada uma grande quantidade de códigos fonte, os eventos dos usuários, á lógica de negócios e os acessos á dados estavam presentes nesta camada, dificultando e muito a programação e a manutenção deste software. Estas aplicações receberam o nome de aplicação monolítica. A partir deste modelo, surgiu á necessidade de criar outra camada especial para o acesso á dados estas passaram a ser chamada de aplicações em duas camadas, onde a camada de acesso a dados ficava em uma máquina especifica e o software era instalado do lado cliente contendo a lógica de negócio e a interface com o usuário.

          Logo após surgiu a aplicação em n camadas, como o objetivo de separar a interface com o usuário, a lógica de negócios e o acesso ao banco de dados, possibilitando que vários usuários interajam com o sistema sem ter necessidade de instalá-las em suas maquinas, tornando o software mais flexível, possibilitando que cada camada seja acessada e modificada individualmente sem ter que modificar outras partes do software.

          Inúmeros problemas podem surgir na construção de sistemas que contiverem mistura de código de acesso a dados junto com á lógica de negócios e a apresentação, essas aplicações são difíceis de manter, pois qualquer alteração que se faça é preciso ter cuidado para não afetar outras partes do sistema.

          Diante desse motivo surgiu na década de 70 segundo Gamma et al., uma arquitetura que foi desenvolvida para ser usada em projetos de interface visual na linguagem de programação Smalltalk, á esta arquitetura recebeu o nome de MVC (Model, View, Controller), que é um padrão arquitetural, o MVC ajuda na tarefa de separar as responsabilidades promovendo um baixo acoplamento e alta coesão, tornando o sistema escalável.     

          Um ponto muito importante aqui é não confundir o MVC com desenvolvimento em camadas, desenvolvimento em três camadas é uma arquitetura para software cliente-servidor e as camadas representam sistemas distintos é fundamental que a camada de apresentação nunca acesse os dados diretamente, isto é, deve passar pela camada intermediária ou pelas camadas intermediárias, pois pode haver n camadas.

          Projetos em multicamadas resolvem vários problemas, mas também podem criar alguns outros, separar a interface do usuário, os dados da aplicação e a lógica de negócios tornam a aplicação como um todo mais fácil de ser compreendida, e permite que diferentes equipes trabalhem de forma paralela em diferentes componentes, mas, possui o seu lado negativo, pois, aumenta o processamento ou armazenamento em excesso, seja de tempo de computação, de memória, de largura de banda, ou qualquer outro recurso que seja requerido para ser utilizado, ou gasto para executar uma determinada tarefa, como consequência pode prejudicar o desempenho do objeto que sofreu o overhead (processamento ou armazenamento em excesso)Obtido em "http://pt.wikipedia.org/wiki/Overhead"

, porém, se você não tomar certos cuidados com as regras da arquitetura  acabará com um sistema mais lento e menos confiável que um sistema em duas camadas, ou uma aplicação monolítica.

Ao iniciar um projeto, em uma maioria, os projetistas e desenvolvedores ficam preocupados com a interface, banco de dados e a linguagem de programação, e ignora a importância que á engenharia de software representa na construção de aplicações, e não se importam em adotar um padrão, ou de elaborar uma documentação de suas aplicações.

          Descrevemos a arquitetura MVC, e os padrões que são adotados em cada camada, retratando o benefício de utilizar um padrão arquitetônico, no planejamento e desenvolvimento de um software dinâmico, bem como, o ganho com essa adoção, quanto á organização do projeto, e ao reuso de códigos fonte, na facilidade de efetuar mudanças.

2. Engenharia de Software

            “A engenharia de software é uma disciplina da engenharia que se ocupa de todos os aspectos da produção de software [...]” (SOMMERVILLE, 2003, p.5).

            Atualmente em nosso cotidiano percebemos algumas empresas de desenvolvimento de software entregando aos seus clientes softwares gigantescos, e de alta complexidade, e dessa maneira alguns sistemas apresentam fracas estruturas, deixando de atender as expectativas dos seus clientes, há ainda outros casos de empresas que atrasam a entrega do software tendo que renegociar os prazos pagando pelo não comprimento da entrega do produto, parte destas empresas desenvolvedoras de software não utiliza nenhum tipo de padrões ou arquitetura no planejamento e execução do software.

 

            Figura 1.1      A evolução do software. (PRESSMAN, 1995, p.5).

            A Figura 1.1 representa a evolução do software, que durante os primeiros anos de desenvolvimento, á parte de hardware sofria inúmeras mudanças, enquanto o software era visto por muitos como uma segunda opção, o desenvolvimento de software era feito sem administração, e por conter poucos métodos, os prazos de entregas eram curtos e na maioria das vezes se esgotavam com essas dificuldades o custo do software aumentava significativamente.

Evolução do software de acordo com PRESSMAN:

1950 – 1960: orientação em lote, distribuição limitada e software customizado.

1970 – 1980: multiusuário, tempo real, banco de dados e produtos de software.

1980 – 1990: sistemas distribuídos, inteligência embutida, hardware de baixo custo.

1990 – 2000: sistemas de desktop poderosos, tecnologias orientadas a objeto, sistemas especialistas, redes neurais e artificiais, computação paralela. (PRESSMAN, 1995, p.5).

            Atualmente em desenvolvimento de projetos principalmente projetos web, não temos dúvidas sobre a vantagem que obtemos ao usarmos uma arquitetura ou padrões que sejam orientados a objetos, as inúmeras vantagens deste progresso já refletiram no barateamento de software e de hardware e na busca do software ideal, onde possamos diminuir as falhas e antecipar os fatores de risco de nossos projetos.

3. Padrões de Projeto

          A constante luta pela qualidade de software vem a anos construindo padrões e técnicas diferentes que auxiliam na construção de sistemas, mas que visam os mesmos objetivos: desenvolver software livre de defeitos, disponibilizarem uma manutenção mais fácil e organizada, um software livre de defeitos é aquele que atendente exatamente com suas especificações, mas não significa necessariamente que o software sempre se comportará como o esperado pelos usuários, razão talvez de algum engano do usuário referente à má utilização do software. É muito difícil construirmos um software livre de defeitos, mas podemos utilizar técnicas de engenharia de software que são fundamentais na organização para construção de aplicações, adotar padrões de projeto ou arquitetura que são padrões de alto nível e são recomendados para grandes aplicações e que nos permite reuso de código fonte, e expansibilidade do software.

         Nas palavras de Metsker “Um padrão é uma maneira de fazer algo, ou de buscar um objetivo. Tal idéia se aplica a cozinhar fazer fogos de artifício, desenvolver software e qualquer outro ofício.” (METSKER, 2004, p.17).

Um padrão pode ser aplicado em diversas áreas para resolver os mais variados problemas que podemos encontrar em nossos ofícios.

“Christopher Alexander foi um dos primeiros escritores a encapsular as melhores práticas de um ofício por meio da documentação de seus padrões. Seus trabalhos estão relacionados à arquitetura de edifícios, não de software.” (METSKER, 2004, p.17).

          De acordo com Metsker, os padrões de projetos começaram com Alexander, um professor de arquitetura em Berkeley, isso mesmo, Alexander é um arquiteto, ele inventou os padrões para construções reais como (casas, prédios, bairros e cidades). Seus relatos sobre padrões tiveram influência na comunidade de software, embora, o que Alexander relatava eram padrões para construção, o que ele descreveu serve como base em relação a os padrões de projetos orientados a objetos.

          Os padrões de projetos não começaram com a GoF (Gang of Four) gangue dos quatro, segundo Metsker, foram eles que começaram com Christopher Alexander. A GoF refere-se ao primeiro catálogo sobre padrões de projetos cuja é formada pelos membros Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Após a publicação deste livro, os padrões de projetos tiveram um maior foco, expandiu-se o número de livros relatando padrões e paradigmas de construção e desenvolvimento de software, mas, o livro de GoF é um dos primeiros, e mais definitivo sobre padrões de projetos.

“[...] Alexander deixa claro que seus padrões o ajudam a servir e inspirar as pessoas que irão ocupar as devidas construções.” (METSKER, 2004, p.18).

          Seguindo o mesmo pensamento de Christopher Alexander, podemos comparar suas idéias e relaciona-las quando projetamos um software, nele procuramos atingir um objetivo: que o software seja de suma importância para nossos clientes, cumprindo com nossos prazos e objetivos para conseguir a aprovação em um nível mais satisfatório possível.

A comunidade de software fez ressoar a abordagem de Alexander e criou muitos livros que documentam padrões de desenvolvimento de software. Estes livros registram as melhores praticas para processo de software, analise de software e projetos de alto nível e no nível de classe. Um padrão de projeto é um padrão uma maneira de alcançar um objetivo o que utiliza classes e seus métodos em uma linguagem orientada a objeto. (METSKER, 2004, p. 18).

         Os desenvolvedores em sua maior parte buscam soluções para seus problemas, ao utilizar padrões de projetos, ou após ter conhecimentos em alguma linguagem de programação, ou ainda já terem programado por algum tempo. Antes disso, talvez observamos que códigos de outros programadores parece mais funcional e mais simples, mas, que exijam um pouco mais de tempo para analisar, e você se pergunta, como este código deste desenvolvedor chegou a tal ponto de simplicidade e funcionalismo.

Com o aumento da complexidade das aplicações a serem desenvolvidas torna-se fundamental o uso de uma arquitetura, ou de padrões de projetos, eles dependem freqüentemente das características como polimorfismo e herança, o principio geral de padrões de projeto é que essa abordagem seja aplicada igualmente a todas as abordagens de projeto de software, de maneira que eles contribuam tal volvedor chegou aossosm nossos projetos  para um bom andamento dos nossos projetos e que nos ajude a cumprir nossas metas. Abaixo abordaremos a arquitetura MVC que tende a cumprir com seus objetivos.

4. Arquitetura MVC

          A arquitetura MVC foi desenvolvida para ser usado em projetos de interface visual em Smalltalk, linguagem de programação que juntamente com o C++ ganhou grande reconhecimento na época, o MVC foi criado na década de 70, e após esses anos de sua criação ainda é um pattern aplicável nas mais variadas aplicações, principalmente em aplicações web.

          O gerenciamento da interface com o usuário é uma tarefa difícil para os desenvolvedores, porém fundamental para o sucesso do sistema, alem da dificuldade, a complexidade na confirmação dos dados onde necessitamos apresentar ao usuário de forma correta e ainda gerenciar a aplicação para os usuários possam controlá-las apropriadamente, é fundamental que as interfaces e o controlador estejam sincronizados.

          Há uma maneira simples de entender o MVC uma vez que, o definimos como um padrão de arquitetura, MVC é o mesmo entendimento de um design pattern: primeiro entendemos o problema (que é a motivação para o surgimento de um padrão), e após entender como este padrão resolve este problemas, e quais as vantagens que ele nos oferece, mas com isso é necessário seguir a risca o MVC.

          Quando um software começa a ficar grande e complexo, muitos dados são apresentados para os usuários, sentimos a necessidade de aplicar uma arquitetura que facilite nosso trabalho, desde a organização do projeto, as divisões das responsabilidades até as possíveis modificações que poderão ser efetuadas ao longo do desenvolvimento do software para isso precisaram dividir o projeto em três objetos para aplicar o MVC.

4.1 Objetivos da Arquitetura

          Para a Gamma et al. o MVC é:

MVC é composto por três tipos de objetos. O modelo é o objeto de aplicação, a vista é a apresentação na tela e o controlador define a maneira como a interface do usuário reage às entradas do mesmo. Antes do MVC, os projetos de interface para o usuário tendiam em agrupar esses objetos. MVC para aumentar a flexibilidade e a reutilização. (GAMMA et al. 2000, p. 20).

          O MVC tem como principal objetivo: separar dados ou lógicos de negócios (Model) da interface do usuário (View) e o fluxo da aplicação (Controller), a idéia é permitir que uma mensagem da lógica de negócios possa ser acessada e visualizada através de várias interfaces. Na arquitetura MVC, á lógica de negócios, ou seja, nosso Model não sabe quantas nem quais as interfaces com o usuário esta exibindo seu estado, a view não se importa de onde esta recebendo os dados, mas ela tem que garantir que sua aparência reflita o estado do modelo, ou seja, sempre que os estados do modelo mudam, o modelo notifica as view para que as mesmas atualizem-se.

4.2 Características da Arquitetura

· Separação entre os códigos, View e Controller que gerencia as relações entre                              o Model e a View.

· Separa a lógica de negócios da apresentação.

· Possui re-usabilidade, podemos criar bibliotecas e adicionar interfaces facilmente.

· É possível desenvolver-lo em paralelo, ou seja, pode começar o projeto por qualquer camada.

· Divide as responsabilidades, ou seja, programadores na programação e web designers na construção visual do software.

· Reduz o esforço na manutenção do software, pois as alterações são efetuadas separadamente não afetando as outras camadas do sistema.

4.3 Arquitetura

Como a arquitetura atua na infra-estrutura dos sistemas, como comunicações, interfaces com usuários e compiladores. Agora abordaremos cada uma das camadas da arquitetura MVC, e o relacionamento com um browser em aplicações web, com os objetos request e response, onde o request é o pedido de uma informação ou evento, e o response é a resposta deste pedido é à saída dos dados depois de efetuado o procedimento request.

           

Figura 1.1 Arquitetura MVC em aplicações web.

           

MVC é um conceito (paradigma) de desenvolvimento e design que tenta separar uma aplicação em três partes distintas. Uma parte, a Model, esta relacionada ao trabalho atual que a aplicação administra outra parte a View esta relacionada a exibir os dados ou informações dessa uma aplicação e a terceira parte, Controller, em coordenar os dois anteriores exibindo a interface correta ou executando algum trabalho que a aplicação precisa completar. (GONÇALVES, 2007, p. 141).

            Model: ou modelo é a camada que contém a lógica da aplicação, é responsável pelas regras de negócio, para sistemas persistentes, o modelo representa a informação (dados) dos formulários e as regras SQL para manipular dados do banco, o modelo mantém o estado persistente do negócio e fornece ao controlador á capacidade de acessar as funcionalidades da aplicação, o modelo é o principal responsável toda aplicação deve representar o modelo atua isoladamente não tem conhecimento de quais serão a ou as interfaces que terá de atualizar, o modelo somente acessa á base de dados e deixa os dados prontos para o controlador este por sua vez encaminha para a visão correta.

          View: ou visão é a camada de apresentação com usuário, é a interface que proporcionará á entrada de dados e a visualização de respostas geradas, nas aplicações web é representado pelo HTML que é mostrado pelo browser, geralmente a visão contém formulários, tabelas, menus e botões para entrada e saída de dados.  A visão deve garantir que sua apresentação reflita o estado do modelo, quando os dados do modelo mudam, o modelo notifica as vistas que dependem dele, cada vista tem a chance de atualizar-se. Desta maneira permite ligar muitas vistas a um modelo podendo fornecer diferentes apresentações, essa camada não contém códigos relacionados á lógica de negócios, ou seja, todo o processamento é feito pelo Modelo e este repassa para a visão, evidenciaremos abaixo um exemplo de duas vistas atuando sobre o mesmo modelo.

Figura 2.1 Duas View atuando em um mesmo modelo, Model: a=100, b=90, c=80.

          Controller: já descrevemos da view e do modelo, mas, temos de concordar que tudo isso se tornaria uma bagunça se tivesse alguém para organizar esta arquitetura, um controlador funciona de intermediário entre a camada de apresentação e a camada de negócios, sua função como já diz é controlar coordenar o envio de requisições feitas entre a visão e o modelo. O controller define o comportamento da aplicação, o controle é quem interpreta as solicitações (cliques, seleções de menus) feitas por usuários com bases nestes requerimentos o controlador comunica-se com o modelo que seleciona a view e atualiza-a para o usuário, ou seja, o controlador controla e mapeia as ações.

          Embora o MVC só contenha três camadas há outra camada fundamental para o bom andamento da arquitetura, esta é um mecanismo de eventos necessário a comunicação entre outros três elementos, este elemento permite uma comunicação assíncrona que é invocada quando algum evento interessante acontece, esta quarta camada contém os beans de entidade onde se localizam os métodos get e set das classes.

5. Design Patterns aplicados na arquitetura MVC

A arquitetura MVC utiliza padrões de projetos em suas camadas analisamos a arquitetura agora com os patterns.

O MVC usa outros padrões de projeto, tais como Factory Method, para especificar por falta (by default) a classe controladora para uma vista e Decarator, para acrescentar capacidade de rolagem (scrolling) a uma vista. Mais os principais relacionamentos do MVC são fornecidos pelos padrões Observer, Composite, Strategy. (GAMMA et al. , 2000, p. 22)

          Os designs patterns nos ajuda á explicar a arquitetura MVC, e com eles podemos perceber que por traz do MVC pode conter um conjunto de padrões trabalhando juntos em uma mesma estrutura. Abordamos agora os patterns Observer e Strategy que são padrões comportamentais e o Composite padrão estrutural, o objetivo de abordar os patterns é para facilitar a compreensão de como a arquitetura MVC trabalha, sabendo que é um padrão de arquitetural que confundem projetistas e desenvolvedores.

          Nas palavras de Gamma et al. os principais padrões que o MVC utiliza são os Observer, Composite e o Strategy. Analisemos a Figura 3 do livro de Padrões de Projetos dos autores Freeman & Freeman que nos ajudará a explicar como os padrões contribuem na arquitetura MVC:

          A visualização ou a View juntamente com o padrão Composite está á disposição do usuário esperando por qualquer evento, quando este evento é ativado o controlador é avisado sobre o evento, este avisa para a visão se atualizar, e ao mesmo tempo manda o modelo para que ele atue para contemplar o evento provocado pelo usuário, depois de atuado o modelo fica pronto para ser acessada pela visualização esta por sua vez acessa e atualiza-se para o usuário assim funciona a arquitetura MVC em conjunto com os padrões de projetos.

Figura 3 (FREEMAN & FREEMAN, p. 424).

5.1 Padrões Estruturais Composite na camada da View.

          Em aplicações gráficas como na interface com o usuário temos um conjunto de componentes aplicados, como botões, menus e caixa de textos.

Os padrões estruturais se preocupam com a forma como as classes e objetos são compostos para formar estruturas maiores. [...] o Composite é um exemplo de padrão estrutural de objetos. Ele descreve como construir uma hierarquia de classe composta para dois tipos de objetos: primitivos e compostos. (GAMMA et al., 2000, p.139).

          O padrão Composite é um padrão estrutural são usados na camada de visão os componentes das telas são compostos. “[...] Quando o controlador determina á visualização que atualize a tela, esta tem de transmitir a ordem ao componente mais alto do nível, porque o padrão Composite cuida do restante.” (FREEMAN & FREEMAN, 2007, p. 424).

            A visualização é composta por vários componentes, componentes de nível mais alto contém outros componentes, que contem outros até chegarem aos nós – folhas, portando quando a informação do controller chega a view manda a ordem para o componente de maior nível.

5.2 Padrões Comportamentais: Observer na camada da Model, e Strategy na camada do Controller.

5.2.1 Padrão Observer

          O Model por sua vez pode fazer o uso do padrão Observer que separa a visão do estado de um objeto do próprio objeto, permitindo que sejam fornecidas visões alternativas mantendo os objetos interessados constantemente informados sobre suas mudanças de estado.

            “Esse padrão pode ser utilizado em todas as situações em que mais de um formato de display para informações de estado pode ser requerido e em que não seja necessário para o objeto que mantém as informações de estado saber sobre os específicos formatos de displays utilizados.” (SOMMERVILLE, 2003, p.273).

            O uso do padrão Observer mantém o modelo totalmente independente das visualizações e controladores, o que nos permite utilizar múltiplas visualizações mesmo tempo como, por exemplo, graficamente ou como texto partindo do mesmo modelo.

           

5.2.2 Padrão Strategy

          O Controller por sua vez adota o padrão Strategy segundo Freeman & Freeman

“A visualização e o controlador utilizam uma estratégia que é fornecida pelo controlador. A visualização só precisa se preocupar com os aspectos visuais do aplicativo, porque todas as decisões sobre o comportamento da interface são delegadas ao controlador, o uso deste padrão mantém a visualização desconectada do modelo, porque a responsabilidade pela iteração com o modelo por executar as solicitações do usuário cabe apenas ao controlador, a visualização não tem a mínima idéia de como isto é feito”. (FREEMAN & FREEMAN, 2007, p. 424).  

É o controller que organiza o MVC por meio de métodos, todas as decisões, estratégias e eventos que podem ser usados pelo usuário é definido nele, a interface só preocupasse em mostrar os dados ao usuário, e reagir segundo as suas programações.

            Utilize padrões de projeto quando tiver absoluta certeza que ele resolverá seu problema, distinguir onde aplicá-los é uma conseqüência de sua experiência e conhecimento, podemos afirmar que é a falta de experiência e conhecimento seja o motivo de outro tópico, os anti-padrões.

6. Anti-Patterns (Anti-Padrões)

          Após a publicação do livro da GoF Soluções Reutilizáveis de Software Orientado a Objeto iniciaram-se um aumento do número de publicações, seminários e outras atividades que referenciava a utilizações de padrões de projetos, muitas pessoas aderiram ao uso de padrões e o uso de padrões por desenvolvedores e arquitetos de software começou a crescer, por sua vez, passaram a surgir de forma naturalmente os anti-padrões do inglês anti-Patterns.

          “Um Anti-Padrão lhe informa como ir de um problema até uma solução ruim.” (FREEMAN & FREEMAN, 2007, p. 478).

Suponha-se que os anti-padrões podem ter como origem a falta de experiência ou de conhecimento de um profissional de desenvolvimento de software que na tentativa de solucionar um problema ou na aplicação de um padrão encontro uma forma errada, ou seja, partiu de um problema até uma solução ruim. Mas quem iria de um problema a uma solução ruim, o anti-padrão mostra que uma solução ruim pode ser atraente, ninguém escolheria uma solução ruim se não se ouve algo lucrativo nela.

          “Um anti-padrão indica que por essa solução é ruim á longo prazo. Para entender um anti-padrão, você compreender como ele exercerá um efeito negativo ao longo do tempo. O anti-padrão descreve onde o uso da solução devera lhe causar problemas.” (FREEMAN & FREEMAN, 2007, p. 479).

Assim como os padrões, os anti-padrões também possuem um nome para que possamos nos referenciar a eles em um vocabulário compartilhado.

Exemplo de um anti-padrão:

Nome: Vidro Quebrado

Problema: você precisa ir ao trabalho de carro, você esqueceu a chave dentro do carro e o carro encontra-se chaveado. Como faço para não me atrasar para o trabalho?

Contexto: tranquei as chaves dentro do carro.

Solução: quebrar a janela entre no carro ligue-o e dirija para o trabalho.

Temos aqui os componentes, o problema que o objetivo a ser alcançado, tem o contexto que a chave que esta dentro do carro esta inacessível e a solução ruim quebrar a janela para não se atrasar no trabalho. Pois bem este é um exemplo de anti-padrão, pois você parte de um contexto (trancar a chave no carro) e chega a uma solução por hora boa que alcançou o seu objetivo que era não se atrasar para o trabalho, mas existe um problema se todo dia você quebrar a janela do carro para alcançar o objetivo terá um enorme prejuízo o custo da janela. Partimos de um problema para uma solução ruim (quebrar a janela).

7. Considerações Finais

No decorrer das ultimas quatro décadas o software evoluiu de uma ferramenta de análise e de informação para uma indústria em si, no entanto esta indústria evoluiu juntamente com os problemas que persistem até hoje, mas, destes problemas boa parte resolvemos aplicando padrões e planejando-o de acordo com a necessidade nossas aplicações. Este artigo dedicou-se no estudo de um dos modelos mais usadas no desenvolvimento de aplicações para web, o MVC apesar de ser de uma longa data se mostra presente em vários frameworks e linguagem, podemos concluir que a arquitetura MVC oferece aos projetistas e desenvolvedores uma clara separação entre os elementos, com o intuito de dividir as funcionalidades de um sistema em camadas, separando as responsabilidades da equipe desenvolvedora, reutilizando códigos fontes, facilitando a manutenção do sistema, pois possuímos escalabilidade, a arquitetura MVC mostra-se fundamental nas aplicações, seja ela web ou desktop.

Use padrões quando houver uma necessidade para aplicar padrões de projeto, e quando houver algo mais simples fique com esta opção caso o contrário ele aumentará a complexidade do sistema, mas, se houver uma razão prática e que seu aplicativo necessitar de mudanças vá em frente e usufrua deste recurso.

Referências

METSKER, Steven John. Padrões de projeto em Java. Porto Alegre: Bookman, 2004.

GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de software Orientado a Objetos. Porto Alegre: Bookman, 2000.

SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Addison Wesley, 2003.

FREEMAN & FREEMAN, Eric & Elizabeth. Padrões de Projetos: Seu cérebro em padrões de projetos. Rio de Janeiro: ALTABOOKS, 2007.

PRESSMAN, Roger S. Engenharia de Software. São Paulo: Pearson Education do Brasil, 1995.

GONÇALVES, Edson. Desenvolvendo aplicações web com JSP, Servlet, Java Server Faces, Hibernate, EJB3 persistence, Ájax. Rio de Janeiro: Ciência Moderna, 2007.